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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 



Introduction 



rd , 



The present document is part of a TS-family covering the 3 Generation Partnership Project; Technical Specification 
Group Services and System Aspects; Telecommunication management; as identified below: 

3GPP TS 32.150: "Integration Reference Point (IRP) Concept and definitions". 

3GPP TS 32. 15 1 : "Integration Reference Point (IRP) Information Service (IS) template". 

3GPP TS 32.152: "Integration Reference Point (IRP) Information Service (IS) Unified Modelling Language 
(UML) repertoire". 
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Scope 



The present document provides the overall concept for all Integration Reference Point (IRP) specifications produced by 
3GPP. Relevant IRP overview and high-level definitions are already provided in 3GPP TS 32.101 [1] and 
3GPPTS 32.102 [2]. 



References 



The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 

[1] 3GPP TS 32.101: "Telecommunication management; Principles and high level requirements". 

[2] 3GPP TS 32.102: "Telecommunication management; Architecture". 

[3] 3GPP TS 32.151: "Telecommunication management; Integration Reference Point (IRP) 

Information Service (IS) template". 

[4] 3GPP TS 32.152: "Telecommunication management; Integration Reference Point (IRP) 

Information Service (IS) Unified Modelling Language (UML) repertoire". 

[5] ITU-T Recommendation M.3020: "TMN Interface Specification Methodology". 

[6] OMG IDL Style Guide, ab/98-06-03, June 17, 1998. 

[7] 3GPP TS 32.1 1 1-2: "Telecommunication management; Fault Management; Part 2: Alarm 

Integration Reference Point: Information Service (IS)". 



Definitions and abbreviations 



3.1 Definitions 

For the purposes of the present document, the terms and definitions given in 3GPP TS 32.101 [1], 3GPP TS 32.102 [2], 
3GPP TS 32.151 [3] and the following apply: 

IRPAgent: See 3GPP TS 32.102 [2]. 

IRPManager: See 3GPP TS 32.102 [2]. 

Interface IRP: 3GPP publishes a number of IRP specifications each of which is related to a set of operations and 
notifications for a specific telecom management domain such as alarm management, configuration management, etc. 
This term represents all such specifications. 

NRM IRP: 3GPP publishes a number of IRP specifications each of which is related to a particular NRM (Network 
Resource Model) as defined in 3GPP TS 32.101 [1]. This term represents all such specifications. 

Data Definition IRP: 3GPP publishes IRP specifications relating to commonly used data definitions that can be 
imported for use by Interface IRP and/or NRM IRP. This term represents all such specifications. 
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YyyIRP: 3GPP defines a number of support-IOCs (defined in Interface IRP) such as AlarmlRP, BasicCMIRP and 
EPIRP. This term represents all such support-IOCs. 



3.2 



Abbreviations 



For the purposes of the present document, the abbreviations given in 3GPP TS 32.101 [1], 3GPP TS 32.102 [2], 
3GPP TS 32.151 [3] and the following apply: 

CMIP Common Management Information Protocol 

CORBA Common Object Request Broker Architecture 

EM Element Manager 

GDMO Guidelines for the Definition of Managed Objects 

GUI Graphical User Interface 

IDL Interface Definition Language 

IOC Information Object Class 

IRP Integration Reference Point 

IS Information Service 

NE Network Element 

NM Network Manager 

NRM Network Resource Model 

OMG Object Management Group 

ORB Object Request Broker 

PSA Product Specific Application 

SMP System Management Processes 

SNM Sub-Network Manager 

SS Solution Set 

TMF TeleManagement Forum 

TOM Telecom Operations Map 

UML Unified Modelling Language 



Integration Reference Points (IRPs) 



4.1 



Introduction 



For the purpose of management interface development 3GPP has developed an interface concept known as Integration 
Reference Point (IRP) to promote the wider adoption of standardized management interfaces in telecommunication 
networks. The IRP concept and associated methodology employs protocol and technology neutral modelling methods as 
well as protocol specific solution sets to achieve its goals. 

4.1.2 General 

The three cornerstones of the IRP concept are: 

Top-down, process-driven modelling approach: The purpose of each IRP is automation of one specific task, 
related to TMF TOM. This allows taking a "one step at a time" approach with a focus on the most important 
tasks. 

Technology-independent modelling: To create from the requirements an interface technology independent 
model. This is specified in the IRP Information Service. 

Standards-based technology-dependent modelling: To create one or more interface technology dependent 
models from the technology independent model. This is specified in the IRP Solution Set(s). 
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IRP REQUIREMENTS 



IRP INFORMATION SERVICE 




iZ 



IRP SOLUTION SETS 



^ 



Figure 4.1 : IRP components (with example Solution Sets) 



4.1 .2 IRP Specifications Approacin 



As highlighted in the previous subclause, IRP interfaces are specified using a 3-level approach: Requirements, IS-level 
specifications and SS-level. 



Requirements / Use Cases 
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Figure 4.2: The IRP 3-Level Specifications Approach 



Level 1: 



The "Requirements-level" intends to provide conceptual and use cases definitions for a specific management 
interface aspect as well as defining subsequent requirements for this IRP. 
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Level 2: 



The "IS-level" provides the technology independent specification of an IRP. From an IS-level perspective there 
are three types of IRP IS specifications: 

• Interface IRPs - providing the definitions for IRP operations and notifications in a network agnostic manner. 

• NRM IRPs - providing the definitions for the Network Resources to be managed through the Itf-N 
(commonly named "Network Resources IRPs"). 

• Data Definition IRPs - providing data definitions applicable to specific management aspects to be managed 
via reusing available Interface IRPs and being applied to NRM IRPs as applicable. 



Level 3: 



The "SS-level" finally provides the mapping of IS definitions into one or more technology-specific Solution 
Sets. This concept provides support for multiple interface technologies as applicable on a vendor and/or network 
type basis and also enables accommodation of future interface technologies - without the need to redefine 
requirements and IS-level definitions. 



4.2 Integration levels 



Virtually all types of telecom/datacom networks comprise many different technologies purchased from several different 
vendors. This implies that the corresponding management solution need to be built by integrating product-specific 
applications from different vendors with a number of generic applications that each provide some aspect of 
multi-vendor and/or multi-technology support. A complete management solution is thus composed of several 
independent applications. 

The following levels of integration are defined: 

Screen Integration: Each application provides its own specific Graphical User Interface (GUI) that need to be 
accessible from a single, unified screen (a common desktop). A seamless integration between the various GUIs 
is then required. Screen Integration is not specified in the present document. 

Application Integration: Applications need to interwork, on a machine-machine basis, in order to automate 
various end-to-end processes of a communication provider. 

4.2.1 Application integration 

Interfaces related to application integration can be divided in the following three categories: 

1) High-level generic interfaces: between generic applications on the network and service management layers. 
The same approach and concepts apply for these as the next category. 

2) High-level (technology-independent to the extent possible) interfaces: between product-specific and generic 
applications are needed in order to automate and streamline frequently occurring tasks applicable to several types 
of network elements. A top-down approach shall be taken when defining these interfaces, where the main input 
is: 

a) business processes of a communication provider; and 

b) the types of generic applications that are used to implement the process support. 

The interfaces need to be stable, open and (preferably) standardized. These IRPs are discussed below under the 
heading Network Infrastructure IRPs. 
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3) Detailed (product-specific) interfaces: between product-specific applications and the corresponding network 
elements are of course also needed. These interfaces are defined using the traditional bottom-up approach, where 
the actual network infrastructure is modelled. This is the traditional TMN approach to element management. The 
management information in these interfaces is not further discussed in the present document, as it is internal to a 
specific development organization and does not need to be open. In fact, by publishing the management 
information in these interfaces, too much of the internal design may be revealed and it may become impossible 
to later enhance the systems that are using the interfaces. The management services (operations and 
notifications) and protocol shall however be open and standardized as long as they are independent of the NRM 
describing the managed NEs/NRs. 

4.3 Network infrastructure I RPs 

When providing integrated management solutions for multi-vendor networks, there is a strong requirement that the NEs 
and the management solutions that go together with them are systems integratable. 

It should be noted that these IRPs could be provided by either the NE, or the Element Manager (EM) or Sub-Network 
Manager (SNM) that goes together with the type of NE. There is actually not a clear distinction any more between NE 
and Element Management applications, mainly due to the increased processing capacity of the equipment platforms. 
Embedded Element Managers providing a web user interface is a common example of that. 

These IRPs are introduced to ensure interoperability between Product-Specific Applications (PSA) and the Network and 
System Management Processes (SMP) of the Network Manager (NM) (3GPP TS 32.101 [1]) shown in figure 4.3. These 
IRPs are considered to cover the most basic needs of task automation. 



I IRP (alternative 2) 

IRP (alternative 1) 




■ Network Manager ■ 



Network & System Management Processes 



Network 

Planning & 

Development 



Network 

Inventory 

Management 



Network 
Provisioning 



Network 
Maintenance 
& Restoration 



\ \ 



Service CM IRPs Common IRPs "^ivi irps 

IRPs (Bulk, Inventory, (Notification, File (Alarm Test 




Network Data 
Management 



PSA = Product Specific Application 
NE = Network Element 



Figure 4.3: IRPs for application integration 

The IRPs presented in figure 4.3 are just an example and do not reflect the exact set of IRPs defined by 3GPP. 

Taking one of the Common IRPs as an example, the Network and System Management Processes have similar need to 
receive notifications from various PSAs. The corresponding service is formalized as a Notification IRP. 
It specifies: firstly, an interface through which subscriptions to different types of notifications can be set-up (or 
cancelled), and secondly, common attributes for all notifications. 

Further, applying a common Name Convention for Managed Objects is useful for co-operating applications that require 
identical interpretation of names assigned to network resources under management. 
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4.4 Defining the IRPs 



It is important to accommodate more than one specific technology, as the technologies will change over time. 
Applications need to be future-proof. One fundamental principle for achieving this is to clearly separate the semantics 
of information definition from the protocols definitions (accessing the information) for the external interfaces. 

The framework being used to define IRPs allows the implementation of user requirements for each management 
capability (e.g. configuration management), by modelling the information related to the resources to be managed and 
the way that the information may be accessed and manipulated. Such modelling is done in a way that is independent of 
the technology and distribution used in the implementation of a management system. 

An IRP for a management capability is composed of three levels of specifications. 

Level 1: 

The first level of IRP specification captures the requirements. 

Level 2: 

The second level of IRP specifications known as "IRP Information Service", specifies the information 
observable and controlled by management system" s client, related to the network resources under management, 
in a technology-independent way. It also specifies the semantics of the interactions used to carry applicable 
information. 

Level 3: 

The third level of IRP specification, known as IRP Solution Set, contains specification of the system in terms of 
interface technology choice (e.g. CMIP/GDMO, CORB A/IDL). In this type of specification, the syntax, rather 
than the semantics, is specified. At least one instance of a Solution Set is produced per interface technology 
supported. 

The IRP methodology uses the following steps: 

a) Capture the management requirements. 

b) Specify the semantics of the information to describe the system. Trace back to item (a). 

c) Specify the semantics of the interactions between the management system and its clients. Trace back to item (a). 

d) Specify the syntaxes of the information and interactions identified in (b) and (c). The specification is technology 
dependent. Trace back to items (b) and (c). 

As described above, the Information Service (IS) specification may contain two parts, the information related to the 
resources to be managed and the way that the information may be manipulated. 



Part 1: 



The first part defines the information types within a distributed system. It is in line with the Analysis phase of 
ITU-T Recommendation M.3020 [5]. From the point of view of the Network Level modelling work it reflects the 
information aspects (including states and significant transitions) of the managed resources and the management 
services. It defines information object classes, the relationships between these object types, their attributes and 
states along with their permitted state transitions. It may also define the allowable state changes of one or more 
information objects. As recommended in ITU-T Recommendation M.3020 [5], UML diagrams (class diagram, 
state diagram) are used to represent information when appropriate. This rest of the specification is described 
using an information description specified in natural language with appropriate label keywords 
(e.g. DEFINITION, ATTRIBUTE, CONSTRAINTS, etc.). A definition of the IS information template is 
provided in annex C. 

Management service specific information objects may be created by subclassing from the objects in the basic 
network model, and extending them for that application. In this case, the new management service specific 
subclass may include other attributes, in addition to those defined in its superclass. Additional relationships and 
attributes may also be created as needed for that management service. Completely new objects can also be 
added. 
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Part 2: 

The second part defines interfaces. Each interface contains one or more operations or one or more notifications 
that are made visible to management service users. An interface encapsulates information exchanged that is 
atomic in the sense that either all the information exchanged are visible (to management service users) or none. 
In addition, the specification of the information exchanged is in semantics only. No syntax or encoding can be 
implied. The operations or notifications are defined with their name, input and output parameters, pre and post 
conditions, raised exceptions and operation behaviour. These operation and notification specifications refer, 
through the utilization of parameter matching, to the information objects. A definition of the IS operations / 
notifications template is provided in annex C. 

The Solution Set (SS) contains the mapping of the information objects and interactions (if applicable) specified 
in the IS-level specification, into their corresponding syntaxes of a particular chosen technology. The mapping is 
interface technology specific and satisfies scenarios where interfaces have been selected, according to mapping 
choices (driven for example by system performance, development cost, time-to-market). The mapping is not 
always one-to-one. General rules valid for all IRP SSs are defined in annex A. Rules for specific SSs, such as 
CORBA, are defined in an Annex to the present document as well as within each of the SS technologies used by 
3GPP (as applicable). 

Managed Object Classes as defined in a CMIP or CORBA Solution Set specifications represent a mapping into 
GDMO or IDL of Information Object Classes and other additional objects classes that can be introduced to 
support interfaces defined in the Information Service. Whether instances of Managed Object Classes are directly 
accessible or not may not be specified by IRP specifications. 

Figure 4.4 shows an example of how an IRP can be structured (the Alarm IRP). 



Alarm IRP: Requirements 



Alarm IRP: Information Service 



Notifications for Alarm reporting and operations possible over the Alarm IRP (Specified in 
UML and natural language). 
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Figure 4.4: Example of an IRP (Alarm IRP) 
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4.5 Relationships among IS-level specifications 

This subclause presents the target architecture of the SA5 IRP Information Models. This architecture is based on the 
concepts of level and partition of information. To achieve this, Information Object Classes (lOCs) and interfaces are 
defined and grouped into packages that can be related to each other through the import relationship. 

Level means that the information models are structured in a way that enables re-utilization between levels, either 
through inheritance or through a traditional relationship between classes. Four levels are identified, namely: 

1) A Generic Network Resource Model, also called "Generic NRM", which defines the information object 
classes that are independent of any: 

1 . protocol (e.g. CORE A / IDL, CMIP / GDMO, etc.); and 

2. "domain specific network" (e.g. UTRAN, GERAN, CN). 

This Network Resource Model contains definitions of the largest subset of information object classes that are 
common to all the Network Resources Models to be defined in SA5. This Network Resources Model is part of 
Level 1 . For this Information Service, a number of solution sets may be provided. 

2) A number of Domain-specific Network Resource Models. Examples of these are: the CN Model, the UTRAN 
Model and the GERAN Model. They are part of Level 2. These Network Resource Models are specified in 
corresponding packages and import information object classes from the Generic Network Resources Model 
defined in Level 1 . For each of these Information Services, a number of solution sets may be provided. 

3) A number of function-specific ISs. Such information services as the Basic CM IRP IS, the Notification IRP IS 
and the Alarm IRP IS are part of this level. They are part of Level 3. These Information Services are specified 
in corresponding packages and may import information object classes and interfaces defined in Level 1 and 2. 
For each of these Information Services, a number of solution sets may be provided. 

4) A number of (interface technology-independent) Information Models. Up to now, none of them have been 
defined. They will be part of Level 4. These Information Models are specified in corresponding packages and 
may import information object classes and interfaces defined both in Level 1, 2 and 3. An example of such 
Information Model could be a "UTRAN Alarm IM" (see figure 4.5). For each of these Information Models, a 
number of solution sets may be provided. 

These levels provide a means for separation of concerns and re-utilization. 

ISs shall be kept as simple as possible. To achieve this. Information Object Classes and interfaces shall be grouped into 
packages. The grouping shall be based on semantics, i.e. information object classes and interfaces that participate in the 
definition of a given IRP should be gathered into a dedicated package. See further example(s) on this in annex C. 

Re-utilization of information specification contained in an IS previously specified shall be possible through the import 
relationship. The import relationship is a means for re-utilization: once a piece of information (i.e. an information object 
class, an attribute, a relationship or an interface) defined in an IS is imported in another IS, it is added to the name space 
of the importing IS. Then, the whole information available in a IS is made up of the information which is owned by the 
IS itself (i.e. defined in the present document) plus the information which is imported from other IS(s). This imported 
information can then be utilized in the importing IS, for instance, through: 

• inheritance (e.g. any information object class defined at Levels 2 to 4 inherits from the information object class 
Top defined in the generic NRM at Level 1), either directly or indirectly; 

• relationship (e.g. any information object class defined at Levels 2 to 4 may have a containment relationship with 
the information object class IRP Agent defined in the generic NRM at Level 1). 

An illustration of this architecture is provided in figure 4.5; it uses the UML diagrammatic conventions. 
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Figure 4.5: Specification architecture (not complete) 

In order not to mix up the concept of "Information Object Class" and "interface" with other concepts such as "Managed 
Object Class" and "manager / agent interface", the former are labelled according to the UML notation capability 
(cf stereotype). "Information Object Class" is defined as a stereotype of "Class" in the UML meta-model. As a 
consequence, information object classes defined in Information Models are labelled «InformationObjectClass». 
Similarly, interfaces are labelled «Interface». In annex C you can find an example of the inheritance between some 
ISs. 

The following piece of information regarding the Semantics of the relationship "import" can be imported from other 
standard documents: 

1. An Information Object Class. The definition of the IOC, the attributes and the roles that the IOC plays in some 
relationships are imported. The import clause shall specify the TS number from which the IOC is imported and 
the name of the IOC. 

2. An attribute. Two cases are valid: 

2. 1 An attribute definition. In this case, the attribute definition is imported. The import clause shall specify the 
TS number from which the attribute is imported and the name of the attribute. 

2.2 An attribute reference within an IOC definition. In this case, the attribute definition is imported together with 
its qualifier within the specified IOC. The import clause shall specify the TS number from which the attribute 
is imported, the name of the IOC and the name of the attribute. 

3. A relationship. The definition of the relationship is imported. The import clause shall specify the TS number 
from which the relationship is imported and the name of the relationship. 

4. An interface. The definitions of the interface and all its operations or notifications are imported. The import 
clause shall specify the TS number from which the interface is imported and the name of the interface. 

5. An operation or a notification. The definition of the operation / notification is imported. The import clause shall 
specify the TS number from which the operation / notification is imported, the name of the interface in which the 
operation / notification is defined and the name of the operation / notification. 
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A piece of information must always be imported from the TS where it is initially defined. It cannot be imported Irom 
any other. 



4.6 Mandatory, Optional and Conditional qualifiers 

This subclause defines a number of terms used to qualify the relationship between the "Information Service", the 
"Solution Sets" and their impact on the IRP implementations. The qualifiers defined in this clause are used to qualify 
IRP Agent behaviour only. This is considered sufficient for the specification of the IRPs. 

Table 4. 1 defines the meaning of the three terms Mandatory, Conditional and Optional when they are used to qualify the 
relations between operations, notifications and parameters specified in "Information Service" documents and their 
equivalents in Solution Set (SS) specifications. 

Table 4.1 : Definitions of Mandatory, Optional and Conditional Used 
in Information Service specifications 





Mandatory (M) 


Conditional (C) 


Optional (0) 


Operation 

and 

Notification 


Each Operation and Notification 
shall be mapped to its 
equivalents in all SSs. 
Mapped equivalent shall be M. 


Each Operation and Notification 
shall be mapped to its equivalents 
in at least one SS. 
Mapped equivalent can be M or 0. 


Each Operation and Notification 
shall be mapped to its 
equivalents in all SSs. 
Mapped equivalent shall be 0. 


Input and 

output 

parameter 


Each parameter shall be mapped 
to one or more information 
elements of all SSs. 
Mapped information elements 
shall be M. 


Each parameter shall be mapped 
to its equivalent in at least one SS. 
Mapped equivalent can be M or 0. 


Each parameter shall be mapped 
to its equivalent in all SSs. 
Mapped equivalent shall be 0. 


Information 
relationship 


Each relationship shall be 
supported in all SS's. 


Each relationship shall be 
supported in at least one SS. 


Each relationship shall be 
supported in all SS's. 


Information 
attribute 


Each attribute shall be supported 
in all SS's. 


Each attribute shall be supported in 
at least one SS. 


Each attribute shall be supported 
in all SS's. 



Table 4.2 defines the meaning of the two terms Mandatory and Optional when they are used to qualify the operations, 
parameters of operations, notifications and parameters of notifications in Solution Sets. 

Table 4.2: Definitions of Mandatory and Optional Used in Solution Set Documents 



Mapped SS Equivalent 


Mandatory 


Optional 


Mapped notification 
equivalent 


IRPAgent shall generate it. 


IRPAgent may or may not generate it. 


Mapped operation equivalent 


IRPAgent shall support it. 


IRPAgent may or may not support this operation. If the 
IRPAgent does not support this operation, the IRPAgent 
shall reject the operation invocation with a reason 
indicating that the IRPAgent does not support this 
operation. The rejection, together with a reason, shall be 
returned to the IRPManager. 


input parameter of the 
mapped operation equivalent 


IRPAgent shall accept and 
behave according to its 
value. 


IRPAgent may or may not support this input parameter. If 
the IRPAgent does not support this input parameter and if 
it carries meaning (i.e. it does not carry no-information 
semantics), the IRPAgent shall reject the invocation with a 
reason (that it does not support the parameter). The 
rejection, together with the reason, shall be returned to the 
IRPManager. 


Input parameter of mapped 

notify equivalent 

AND 

output parameter of mapped 

operation equivalent 


IRPAgent shall generate it. 


IRPAgent may generate it. 
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4.7 System context for Interface IRPs 

Every Interface IRP on the Itf-N interface (e.g. Alarm IRP, Notification IRP, Basic CM IRP, Bulk CM IRP) is subject 
to a System Context as described in this subclause (also consistent with 3GPP TS 32.102 [2] clause 8). 

Figure 4.6 and 4.7 identify system contexts of the Interface IRP in terms of its implementation, called IRP Agent, and 
the user of the IRP Agent, called IRPManager. For a definition of IRPManager and IRP Agent, see 3GPP TS 32.102 [2]. 

Each IRP Agent implements and supports one or more IRPs. The set of IRPs that is related to each Interface IRP is 
defined by the System Context subclause in each individual Interface IRP IS specification, e.g. subclause 4.2 in the 
Alarm IRP IS [7]. 

An NE can be managed via System Context A or B. The criterion for choosing System Context A or B to manage a 
particular NE is implementation dependent. An IRP Agent shall support one of the two System Contexts. By observing 
the interaction across the Itf-N, an IRPManager cannot deduce if the EM and NE are integrated in a single system or if 
they run in separate systems. 



IRPManager 



NM 



IRPAgent 



Itf-N 




NEs 



EM 



Supported IRP(s) 



Figure 4.6: System Context A 
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Figure 4.7: System Context B 
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Annex A (informative): 
General rules for Solution Sets 

A.1 Introduction 

The intent of this annex is twofold. The first intent is for 3GPP-internal use to document how a 3GPP Solution Set is 
produced and what it shall contain. The second intent with the annex is to give the reader of an Information Service (IS) 
or a Solution Set (SS) a better understanding on how to interpret the IS or SS specifications. 



A.2 Solution Set (SS) versioning 

For further study. 



A.3 Referenced Information Service (IS) specification 

A sentence shall be included in the clause "Scope" of all Solution Set specifications. The sentence shall read as follows: 

"This Solution Set specification is related to Z". 

where Z is the 3GPP Information Service (IS) specification number including the version, such as "TS 32.1 1 1-2 
V4. 1 .X" for the case of Alarm Integration Reference Point (IRP): Information Service. 

NOTE: that "X", rather than the actual digit, is actually used in the sentence. This is because the value of X is not 
relevant for the reference purpose since different values of X identify different 3GPP published 
specifications that reflect only minor editorial changes. 
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Annex B (normative): 

Rules for CORBA Solution Sets 

B.1 Introduction 

The intent of this annex is threefold. 

1) The first intent is for 3GPP internal use to document how a 3GPP CORBA SS is produced and how it is 
structured. 

2) The second intent with the annex is to give the reader or implementer of a CORBA SS a better understanding on 
how to interpret the CORBA SS specification. 

3) The third and maybe most important intent is to put requirement on an implementer of a CORBA SS. 
It is expected that this annex is to be extended in later versions of the present document. 

B.2 Rules for specification of CORBA Solution Sets 
B.2.1 Introduction 

This subclause identifies rules for specification of CORBA SSs. This subclause is mainly for 3GPP-internal use. It is 
only for information for the implementer of a CORBA SS. 

B.2. 2 Pragma prefix 

All IDL-code shall define the pragma prefix using the following statement: 

#pragma prefix "3gppsa5.org" 
See clause D. 1.4.3 for information of this #pragma statement in relation to other IDL statements. 

B.3 Implementation aspects of CORBA Solution Sets 
B.3.1 Introduction 

This subclause identifies rules for the implementation of CORBA SSs. This subclause is normative for the implementer 
of a CORBA SS. 

B.3. 2 IRPAgent behaviour on incoming optional method 

The IRPAgent, claiming compliance to a particular SS version of a particular IRP such as the Alarm IRP, shall 
implement all Mandatory and all Optional methods. Each method implementation shall have a signature specifying all 
Mandatory and all Optional parameters. 

• If the IRPAgent does not support a particular optional method, it shall throw the OperationNotSupported 
exception when the IRPManager invokes that method. 

• If the IRPAgent have not implemented a particular method (because it is compiled with an IDL version that does 
not define the method), the CORBA ORB of the IRPAgent shall throw a system exception if the IRPManager 
invokes that method. 
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In all the above cases when an exception is thrown, the IRP Agent shall restore its state before the method invocation. 

B.3.3 IRPAgent Behaviour on incoming optional parameter of 
operation 

An IRPAgent must implement all optional parameters, as well as mandatory parameters, in all methods. 

If the IRPAgent supports the implemented method but does not support its (one or more) optional input parameters, 
upon method invocation, the IRPAgent shall check if those parameters carry "no information" or absence semantics 
(defined later in subclause B.3.5). If the check is negative, the IRPAgent shall throw the ParameterNot Supported 
exception with a string carrying the name of the unsupported optional parameter. 

B.3.4 IRPAgent Behaviour on outgoing attributes of Notification 

CORBA SS uses OMG defined structured event to carry notification. The structured event is partitioned into header and 
body. 

The absence semantics of attribute in the header is realized by a string of zero length. 

The body consists of one or more name-value pair attributes. The absence semantics of these attributes is realized by 
their absence. 

For optional sub -attributes of an attribute carried by the name-value pair, their absence semantics is realized by the 
encoding rule of "absence semantics". See subclause B.3.5. 

B.3.5 Encoding rule of absence semantics 

The operation parameters are mapped to method parameters of CORBA SS. The absence semantics for an operation 
(input and output) parameter is method parameter type dependent. 

• For a string type, if the parameter is specified as a string type, the absence semantics is a string of zero length. If 
the parameter is specified as a union structure (preferred), the absence semantics is conveyed via a FALSE 
Boolean value switch. 

• For an integer type, if the parameter is specified as a signed, unsigned, long, etc type, the absence semantics is 
the highest possible positive number. If the parameter is specified as a union structure (preferred), the absence 
semantics is conveyed via a FALSE Boolean value switch. 

• For a boxed valueType (supported by CORBA 2.3), it is the null value. 

The notification parameters are mapped to attributes of the CORBA Structured Events. The absence semantics for a 
notification parameter is attribute position (within the Structured Event) dependent. 

• For the fixed header of the Structured Event header, the absence semantics is realized by a string of zero length. 

• For the filterable body fields of the Structured Event body, the absence semantics is realized by the absence of 
the corresponding attribute. 



B.4 Void 
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Annex C (informative): 

Example of inheritance between ISs 

Figure C.l illustrates the architecture defined in clause 4.6 with a simplified example. This figure is for illustration only. 
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Figure C.1 : Example of possible packages together 
with Information Object Classes (lOCs) and their inter-relationships 

The following aspects are illustrated in figure C. 1 : 

1) lOCs that are common to all Network Resources Models / some Information Services are captured in the 
GenericNRM package: Top, IRPAgent, GenericIRP, together with their attributes and relationships. 

2) The IOC BasicCmIRP is defined in the BasicCmIRP IS package. As illustrated in the previous figure, this 
package imports the GenericNRM package. 

3) The IOC AlarmlRP is defined in the AlarmlRP IS package. As illustrated in the previous figure, this package 
imports the GenericNRM package. 

4) As a consequence, every IOC can inherit from the class Top, either directly or indirectly. 

5) The IRPAgent class is defined in the GenericNRM. 

6) A GenericIRP IOC is defined in the Generic NRM. It represents an abstraction of all the IRPs such as, 
e.g. BasicCmIRP or AlarmlRP. A containment relationship between IRPAgent and GenericIRP is defined. 
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7) Both the lOCs BasicCmIRP and AlarmlRP (defined in different ISs) inherit from GenericIRP. As a first 

consequence, they inherit the attributes IRPId and IRPVersion (from GenericIRP) and objectClass (from Top). 
As a second consequence, both BasicCmIRP and AlarmlRP are contained in IRP Agent. 
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Annex D (informative): 

Style Guide for CORBA SS IDL 



This annex is the style guide for writing IDL statements for Interface IRP and NRM IRP. The guidelines are largely 
based on the OMG IDL Style Guide (OMG document: ab/98-06-03) [6] with extensions for 3GPP IRP use. 

The guide sets out consistent naming, structural conventions and usage of SS interface for the IDL in 3GPP IRP 
CORBA SS specifications. 



D.1 IVIodules and File 
D.1.1 Use of Modules 

All declarations of IDL shall be contained in modules. No declarations of interfaces and definitions shall appear in the 
global scope. 

Nesting modules is a useful technique when dealing with large namespaces to avoid name clashes and clarify 
relationships. A module nested within another module shall not have the same name as a top-level module in any other 
IRP CORBA SS specification. 

D.1.2 File Names 

CORBA SS specifications contain IDL statements. 
The rule defined below specifies: 

a) How to partition/extract these IDL statements to be placed in a file; and 

b) How to name the file. 

Note that IDL uses "# include "x" " statement where X is a name of a file containing IDL statements. 
Rule: 

In the annex where IDL statements are defined, use a special marker to indicate that a set of IDL statements shall be 
contained in one file. The name of the file shall be the name of the first IDL module, concatenated with four 
characters ' . idl'. Within a CORBA SS, multiple markers (implying multiple files), can be used. 

It is not allowed to have an IDL module split into multiple files. 



D.1.3 Include Conventions 

All included IDL files shall be specified using the <„.> form of #include. For example: 

#include <ManagedGenericIRPConstDef s . idl> 

D.1.4 File Structure 

D. 1.4.1 File Internal Identification 

The first line of the IDL file shall contain '//File : ' followed by a single space followed by the name of the file. For 
example. 
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//File: ExamplelRPConstDef s . idl 

D. 1.4.2 File Guard 

An IDL file shall use a guard (consisting of three pre-processor lines) to avoid multiple definition errors. An example of 
a guard for the file called TestManagementlRPConstDef s . idl is: 

tifndef _TestManagementIRPConstDef s_idl_ 
#def ine _TestManagementIRPConstDef s_idl_ 

. . . remainder of the IDL 

#endif // _TestManagementIRPConstDef s_idl_ 

D.1.4.3 Required Contents 

If any other files are to be included, the #include statements come after the guard. 

After #include hues, if any, and immediately before the module statement, the following line shall appear: 

#pragma prefix "3gppsa5.org" 

D.1 .4.4 Example illustrating a File Structure 

//File: ExamplelRPConstDef s . idl 
#ifndef _EXAMPLE_IRP_CONST_DEFS_IDL_ 
#define _EXAMPLE_IRP_CONST_DEFS_IDL_ 

// This module describes/is part of... 
# include "Example I ncludeOne . idl" 
tinclude "ExamplelncludeTwo . idl" 

#pragma prefix "3gppsa5.org" 
module ExamplelRPConstDef s ( 

// IDL Definitions here 

}; 

#endif // _EXAMPLE_IRP_CONST_DEFS_IDL_ 

D.2 Identifiers 

D.2.1 Mixed Case, Beginning Upper, No Underscores 

The following categories of identifiers follow the Mixed Case, Beginning Upper, No Underscores rules: 

• module 

• interface 

• typedef 

• Constructed types (struct, union, enum) 

• exception 



£75/ 



3GPP TS 32.1 50 version 6.4.0 Release 6 24 ETSI TS 1 32 1 50 V6.4.0 (2005-09) 

The 'No underscores' rule is also applicable to all words that begin with an upper case letter with the remaining letters 
being lower case. 

As a further note on naming, it is not necessary to append the value 'Type' to an identifier. The fact that it is a type is 
obvious from the consistent application of this naming convention. 

Examples: 

module PMIRPConstDef s (...) ; 
interface AttributeNameValue (...) ; 

D.2.2 Lower Case with Underscores 

The following categories of identifiers follow the Lower Case with Underscores rules. All letters are lower case and 
words (if more than one) are separated with underscores. 



• Operation name and notification name 

• Attribute name 

• Parameter name 

• Structure member name 
Examples: 



get_notif ication_categories (...) ; 
string comment_text ; 

void get_alarm_count (..., out unsigned long critical_count, . . ) , 
struct Comment (...; string user_id; string system_id; . . } ; 



D.2.3 Upper Case with Underscores 



The following categories of identifiers follow Upper Case with Underscores rules. All letters are in upper case and 
words have an underscore separating them. 



• Enum value 

• Constant 
Examples: 



enum SubscriptionState (ACTIVE, SUSPENDED, INVALID} 
const string JOB_ID = "JOB_ID"; 



D.2.4 Naming IDL Sequence Types 



Typically a new type declared as an IDL sequence of another type will have the text 'List' appended to the name of the 
base type. Another convention is to declare such types as unordered sequences or ordered sets for consistency with 
ASN.l notation. In this case they should have the 'Seq' or 'Set' (instead of 'List') appended respectively. 

Example of an 'ordered set': 

typedef sequence <SubscriptionId> SubscriptionldSet ; 
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D.3 Interface IRP 



Every Interface IRP should have 3 IDL modules (each specified in a separate IDL file): 

module YyyIRPConstDef s {...}; // no change from Rel-5 practice. 

module YyyIRPSystem {...}; // no change from Rel-5 practice. 

module YyyIRPNotif ications {...}; // new compared to Rel-5 practice 

The first module defines all necessary IDL constructs, such as constant strings and type definitions, for the methods and 
notifications. The second module defines the methods. The third module defines the notifications. 



D.3.1 . Constant String and Type Definitions 

This first module defines all necessary IDL constructs used by the methods (defined in the second module) and 
notifications (defined in the third module). The name of this module is YyyIRPConstDef s where Xxx is the name of 
the subject Interface IRP. An example is 'PMIRPConstDef s'. 

Within this module, define data types used in the methods. 

Also, define the data types of the attribute values used in the notifications. 

CORBA SS authors should always check the generic types defined in 'ManagedGenericIRPConstDef s' before 
creating a new type. 

For the attribute names of the structured notifications, define an interface AttributeNameValue that captures the 
string definitions. Make sure these definitions do not clash with those defined for the notification header, 
i.e. notification id, event time, system DN, managed object class and managed object instance 

(see Notif icationlRPNotif ication : :Notify). 

An example from PMIRPConstDef s: 
/** 

* This block identifies attributes which are included as part of the 

* PMIRP . These attribute values should not 

* clash with those defined for the attributes of notification 

* header (see IDL of Notification IRP) . 
*/ 

interface AttributeNameValue 
{ 

const string JOB_ID = "JOB_ID"; 

const string JOB_STATUS = " JOB_STATUS" ; 

const string REASON = "REASON"; 

const string MONITOR_ID = "MONITOR_ID" ; 

const string MONITOR_STATUS = "MONITOR_STATUS" ; 



D.3.2 Operations 



The second module defines the methods. The name of the module is YyyIRPSystem where Yyy is the name of the 
subject Interface IRP. An example is AlarmlRP System. 

At the beginning of this module, define all required exceptions. Naming conventions for exception are covered in 
D.2.1 above. CORBA SS authors should always check if the generic exceptions defined in the 

ManagedGenericIRPSystem can be reused before declaring new exception types. 
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Then define one interface called YyyIRP encapsulating all methods of the subject Yyy Interface IRP. If the subject 
Interface IRP IS specifies that its YyyIRP inherits from XxxIRP, then reflect the inheritance relation in the interface 
definition. The following is an example of AlarmlRP that inherits from ManagedGenericIRP . 

module AlarmlRPSystem 
{ 

interface AlarmlRP : ManagedGenericIRPSystem: : ManagedGenericIRP {...}; 



Naming conventions for operations are covered in D.2.2 above. 

D.3.3 Notifications 

Use a separate module to define the notifications. The name the module is YyyIRPNotif ications where Yyy is 
the name of the subject Interface IRP. Examples are KernelCMIRPNotif ications and 
PMIRPNot if ications. 

For NotificationlRPNotif ications, do: 

• Define one IDL interface Not i f y. Capture the four constant strings that are the names of the four NV (name 
value) pairs of f ilterable_body_f ield of the CORBA structured event. These four CORBA NV pairs 
are mapped from the five notification header attributes (defined by the Notification IRP IS), i.e. the 

objectClass, ob jectlnstance, notif icationid, eventTime and systemDN. 

For YyyIRPNotif ications where Yyy is not Notification, do: 

• At the beginning of this module, define the const strings for the notification types that correspond to the set of 
notifications specified by (and not inherited by and not imported by) the subject Interface IRP. 

• Then define a number of IDL interfaces corresponding to notifications specified in the subject Interface IRP. 
These interfaces should inherit from Notif icationIRPNotifications::Notify. Within each 
interface, the first IDL statement defines the notification type (that is used as the second field of the fixed 
header of the structured notification). The second and subsequent IDL statements define the attribute names of 
this notification type, excepting those already defined by Notif icationIRPNotifications::Notify. 
The data type of the attribute value, which is defined in Yyy IRP Cons tDefs, should be mentioned in the 
comment block of this IDL statement. 

• Then define a number of IDL interfaces corresponding to notifications imported, if any. These interfaces 
should inherit from the imported interface. An example is interface NotifyOb jectCreation : 
KernelCMIRPNotif ications:: NotifyOb jectCreation. Within this interface, define all necessary 
IDL constructs, if any, which are not defined in the imported interface. This interface may contain no IDL 
statement if the IDL constructs defined in the imported interface are sufficient. For each interface imported, 
insert a comment The first field of this notification carries the IRP Version of this CORBA SS.' 



• 



There is no need to re-define interfaces for notifications that are already specified in other Interface IRP, and 
from which the subject IRP inherits. 



The following is an extract from PMIRPNotif ications. 

module PMIRPNotif ications 
{ 

const string ET_MEASUREMENT_JOB_STATUS_CHANGED = "notif yMeasurement JobStatusChanged" ; 
const string ET_THRESHOLD_MONITOR_STATUS_CHANGED = "notif yThresholdMonitorStatusChanged" 

interface NotifyMeasurement JobStatusChanged; Notif icationlRPNotif ications ; ;Notify 
{ 

const string EVENT_TYPE = ET_MEASUREMENT_JOB_STATUS_CHANGED; 
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/** 

* This constant defines the name of the jobid property, 

* which is transported in the f ilterable_body fields. 

* The data type for the value of this property 

* is PMIRPConstDefs : : JobldType. 
*/ 

const string JOB_ID = PMIRPConstDefs :: AttributeNameValue :: JOB_ID; 



}; 



interface NotifyXXX : Notif icationlRPNotif ications : :Notify 



}; 



D.4 NRM IRP 



Use one module to define the IDL constructs for the managed object classes. The name of this module is 
XxxNRIRPConstDef s where Xxx is the name of the subject NRM IRP. 

An example is UtranNRIRPConstDef s. 

Within the module, define a set of IDL interfaces each of which corresponds to a managed object class specified. The 
interface definition respects the inheritance relation specified. An example of managed object class RncFunction, 
which inherits from Gene r icNRIRP Con stDefs : :ManagedFunction, is shown below. 

module UtranNRIRPConstDef s 
{ 



* Definitions for MO class RncFunction 

*/ 
interface RncFunction : GenericNRIRPConstDef s ; ;ManagedFunction 
{ 

const string CLASS = "RncFunction"; 

// Attribute Names 

// 

const string rncFunctionId = "rncFunctionId" ; 

const string mcc= "mcc"; 
const string mnc= "mnc"; 
const string rncld= "rncid"; 
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Submitted to TSG SA#22 for Information 


-- 


1.0.0 




Mar 2004 


SA 23 


SP-040113 


-- 


-- 


Submitted to TSG SA#23 for Approval 


-- 


2.0.0 


6.0.0 


Sep 2004 


SA 25 


SP-040559 


0001 


-- 


Add Style Guide for CORBA SS IDL 


B 


6.0.0 


6.1.0 


Dec 2004 


SA 26 


SP-040790 


0002 


-- 


Add Generic System Context 


F 


6.1.0 


6.2.0 


Jun 2005 


SA 28 


SP-050329 


0003 


-- 


Change symbol used in IDL include statements 


F 


6.2.0 


6.3.0 


Sep 2005 


SA 29 


SP-050461 


0004 


-- 


Add missing definitions for IRP types 


F 


6.3.0 


6.4.0 
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